1. Field of the Invention
The present invention relates generally to the creation of computer programs and, more particularly, to a development system with methodologies for capturing and facilitating reuse of software development knowledge and intent.
2. Description of the Background Art
Before a digital computer may accomplish a desired task, it must receive an appropriate set of instructions. Executed by the computer's microprocessor, these instructions collectively referred to as a “computer program”, direct the operation of the computer. Expectedly, the computer must understand the instructions which it receives before it may undertake the specified activity.
Owing to their digital nature, computers essentially only understand “machine code”, i.e., the low-level, minute instructions for performing specific tasks—the sequence of ones and zeros that are interpreted as specific instructions by the computer's microprocessor. Since machine language or machine code is the only language computers actually understand, all other programming languages represent ways of structuring human language so that humans can get computers to perform specific tasks.
While it is possible for humans to compose meaningful programs in machine code, practically all software development today employs one or more of the available programming languages. The most widely used programming languages are the “high-level” languages, such as C, C++, Pascal, Java, or more recently Perl, PHP, and C#. These languages allow data structures and algorithms to be expressed in a style of writing that is easily read and understood by fellow programmers.
A program called a “compiler” translates these instructions into the requisite machine language. In the context of this translation, the program written in the high-level language is called the “source code” or source program. The ultimate output of the compiler is a compiled module such as a compiled C “object module”, which includes instructions for execution ultimately by a target processor, or a compiled Java class, which includes bytecodes for execution ultimately by a Java virtual machine. A Java compiler generates platform-neutral “bytecodes”, an architecturally neutral, intermediate format designed for deploying application code efficiently to multiple platforms.
Integrated development environments, such as Borland's JBuilder® and C# Builder, are the preferred application development environments for quickly creating production applications. Such environments are characterized by an integrated development environment (IDE) providing a form painter, a property getter/setter manager (“inspector”), a project manager, a tool palette (with objects which the user can drag and drop on forms), an editor, a debugger, and a compiler. In general operation, the user “paints” objects on one or more forms, using the form painter. Attributes and properties of the objects on the forms can be modified using the property manager or inspector. In conjunction with this operation, the user attaches or associates program code with particular objects on the screen (e.g., button object). Typically, code is generated by the IDE in response to user actions in the form painter and the user then manipulates the generated code using the editor. Changes made by the user to code in the editor are reflected in the form painter, and vice versa. After the program code has been developed, the compiler is used to generate binary code (e.g., Java bytecode) for execution on a machine (e.g., a Java virtual machine).
During the process of software development, the developer uses the IDE to write a large amount of code. As a result, most projects of even modest complexity will result in the creation of large sections of new source code. As software development today has remained a time and resource intensive task, there is great interest in improving the efficiency of developers. Most of the efforts to date have focused on improving reusability—that is, the reuse of source code. For example, “application generators” have long been used to generate scaffolding or boilerplate sections of code (i.e., recurring, common code/functionality), which may be dumped into a project in the IDE. Notwithstanding the efficiency gain realized by using application generators, software development still remains a resource-consuming task. Thus, there is much interest in further improving the software development process.
Today, the development of any particular program is heavily dependent on the knowledge of the individual or individuals doing the actual development. A persistent problem faced by all developers is how to transfer knowledge between team members, such as transferring an architect's intent in code for subsequent developers to build on. Stating the problem more generally, prior art development systems fail to capture developer intent and thus lose the opportunity to allow the developer's knowledge to be reused. If one member of the team developed special knowledge, that knowledge remains in the developer's head and is not shared through the IDE with other team members. This leads to a situation where developers are constantly reinventing “the same wheel.” Once the developer leaves the team, for example, it is not uncommon for that developer's code to essentially become a “black box,” that is, code whose functionality is poorly understood by other team members. In that scenario, the reusability of the code may be limited. In the real world, this problem frequently arises when team members specialize in one area (e.g., implementing the Web interface of an application) need to know where to fix a problem in another area (e.g., fixing the persistence layer). For instance, where—that is, at what specific code snippets and reusable components—do the Web interface team members even begin? Do they have appropriate access to those items, or are those items even available anymore?
Consider how much “other people's code” a Java developer faces. In Java programs, it is not uncommon for 80% of the code to be support code (i.e., scaffolding or boilerplate code), with only about 20% of the code reflecting the program logic that the developer really wanted to write. Using a traditional IDE, the developer can navigate the project in a file-based hierarchical manner (i.e., projects, folders, files, etc.). However, since the ratio between support code and custom code has become so lopsided, the task of navigating the code in an IDE becomes burdensome. What the developer really wants is a sensible way to navigate the code in an application-centric manner (i.e., accounting, payment system, etc.), not an IDE-centric manner.
The fact of the matter is that applications are becoming more complex and involve increasing numbers of layers and frameworks. As a result, developers are obliged to become specialists with detailed, but tightly circumscribed knowledge of a small cadre of technologies that inhibits expertise or even exposure to technologies in other parts of the same application. The result is that knowledge becomes increasingly “siloed” and knowledge transfer is difficult and, at times, nearly impossible. Even within the same subteam, members can find it difficult to leave useful “bread crumb” trails for developers who will come behind them. Likewise, they have difficulty mining the knowledge of existing team members unless they work geographically close enough and can ask in person. As projects become more complex, this problem emerges as a gating factor to timely product delivery, correct functionality, responsiveness to changing requirements, and (crucially) the ability to promptly and properly resolve defects. Despite being pervasive, the problem is little understood and, until now, inadequately addressed by prior art developer tools.